home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Section Six - OSI Realization
- 25. Overview
- This section describes how the MHS is realized by means of OSI.
- This section covers the following topics:
- a) Application service elements
- b) Application contexts
- 26. Application Service Elements
- This clause identifies the application service elements (.I.ab:ASEs;) that
- figure in the OSI realization of Message Handling.
- In OSI the communication capabilities of open systems are organized into groups
- of related capabilities called ASEs. The present clause reviews this concept from
- the OSI Reference Model, draws a distinction between symmetric and asymmetric
- ASEs, and introduces the ASEs defined for or supportive of Message Handling.
- Note Besides the ASEs discussed, the MHS relies upon the Directory Access
- Service Element defined in Recommendation X.519. However, since that ASE does not
- figure in the ACs for Message Handling (see Recommendation X.419), it is not discussed
- here.
- 26.1 The ASE Concept
- The ASE concept is illustrated in Figure 12/X.402, which depicts two
- communicating open systems. Only the OSI-related portions of the open systems, called AEs, are
- shown. Each AE comprises a UE and one or more ASEs. A UE represents the
- controlling or organizing portion of an AE which defines the open system's role (e.g., that
- of an MTA). An ASE represents one of the communication capability sets, or
- services (e.g., for message submission or transfer), that the UE requires to play its
- role.
- The relationship between two AEs in different open systems is called an
- application association. The ASEs in each open system communicate with their peer ASEs in
- the other open system via a presentation connection between them. That
- communication is what creates and sustains the relationship embodied in the application
- association. For several ASEs to be successfully combined in a single AE, they must be
- designed to coordinate their use of the application association.
- +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11
- | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | |
- 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
- Figure .F.:12/X.402 The ASE Concept
- An ASE plays the largely mechanical role of translating requests and responses
- made by its UE to and from the form dictated by the application protocol that
- governs the ASE's interaction with its peer ASE in the open system to which the
- association connects it. The ASE realizes an abstract service, or a part thereof, for
- purposes of OSI communication (see Recommendation X.407).
- Note Strictly speaking, an open system's role is determined by the behavior of
- its application processes. In the Message Handling context an application process
- realizes a functional object of one of the types defined in clause 7. A UE in turn
- is one part of an application process.
- 26.2 Symmetric and Asymmetric ASEs
- The following two kinds of ASE, illustrated in Figure 13/X.402, can be
- distinguished:
- a) .I.gl:symmetric;: Said of an ASE by means of which a UE both supplies and
- consumes a service. The ASE for message transfer, e.g., is symmetric because both
- open systems, each of which embodies an MTA, offer and may consume the service of
- message transfer by means of it.
- b) .I.gl:asymmetric;: Said of an ASE by means of which a UE supplies or consumes
- a service, but not both, depending upon how the ASE is configured. The ASE for
- message delivery, e.g., is asymmetric because only the open system embodying an MTA
- offers the associated service and only the other open system, which embodies a UA
- or MS, consumes it.
- +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11
- | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | |
- 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
-
-
-
-
-
-
-
-
-
-
-
- Figure .F.:13/X.402 Symmetric and Asymmetric ASEs
- With respect to a particular asymmetric ASE, one UE supplies a service which the
- other consumes. The ASEs co-located with the UEs assist in the service's supply
- and consumption. The resulting four roles are captured in Figure 14/X.402 and in the
- following terminology:
- a) x-.I.gl:supplying UE;: An application process that supplies the service
- represented by asymmetric ASE x.
- b) x-.I.gl:supplying ASE;: An asymmetric ASE x configured for co-location with
- an x-supplying-UE.
- c) x-.I.gl:consuming UE;: An application process that consumes the service
- represented by asymmetric ASE x.
- d) x-.I.gl:consuming ASE;: An asymmetric ASE x configured for co-location with
- an x-consuming-UE.
- +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11
- | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | |
- 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
- Figure .F.:14/X.402 Terminology for Asymmetric ASEs
- As indicated, the four roles described above are defined relative to a particular
- ASE. When an AE comprises several asymmetric ASEs, these roles are assigned
- independently for each ASE. Thus, as shown in Figure 15/X.402, a single UE might serve
- as the consumer with respect to one ASE and as the supplier with respect to
- another.
- +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11
- | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | |
- 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
- Figure .F.:15/X.402 Multiple Asymmetric ASEs
- 26.3 Message Handling ASEs
- The ASEs that provide the various Message Handling services are listed in the
- first column of Table 11/X.402. For each ASE listed, the second column indicates
- whether it is symmetric or asymmetric. The third column identifies the functional
- objects--UAs, MSs, MTAs, and AUs--that are associated with the ASE, either as consumer
- or as supplier.
- Table .T.:11/X.402 Message Handling ASEs
- +------+------+--------------------+ | | | Functional Objects | |
- | +--------------------+ | ASE | Form | UA MS MTA AU | +------+------+--------------------+ | MTSE | SY | - - CS - | +------+------+---------
- ------------+ | MSSE | ASY | C CS S - | | MDSE | ASY | C C S
- - | | MRSE | ASY | C S - - | | MASE | ASY | C CS S - | +--
- -----+------+--------------------+ +- Legend -------------------+ | SY symmetric
- C consumer | | ASY asymmetric S supplier | +----------------------------+
- The Message Handling ASEs, summarized in the table, are individually introduced
- in the clauses below. Each is defined in Recommendation X.419.
- 26.3.1 Message Transfer
- The Message Transfer Service Element (.I.ab:MTSE;) is the means by which the
- transfer transmittal step is effected.
- 26.3.2 Message Submission
- The Message Submission Service Element (.I.ab:MSSE;) is the means by which the
- submission transmittal step is effected.
- 26.3.3 Message Delivery
- The Message Delivery Service Element (.I.ab:MDSE;) is the means by which the
- delivery transmittal step is effected.
- 26.3.4 Message Retrieval
- The Message Retrieval Service Element (.I.ab:MRSE;) is the means by which the
- retrieval transmittal step is effected.
- 26.3.5 Message Administration
- The Message Administration Service Element (.I.ab:MASE;) is the means by which a
- UA, MS, or MTA places on file with one another information that enables and
- controls their subsequent interaction by means of the MSSE, MDSE, MRSE, and MASE.
- 26.4 Supporting ASEs
- The general-purpose ASEs upon which Message Handling ASEs depend are listed in
-
-
-
-
-
-
- the first column of Table 12/X.402. For each listed ASE, the second column indicates
- whether it is symmetric or asymmetric.
- Table .T.:12/X.402 Supporting ASEs
- +------+------+ | ASE | Form | +------+------+ | ROSE | SY | | RTSE | SY | |
- ACSE | SY | +------+------+ +- Legend -------+ | SY symmetric | | ASY
- asymmetric | +----------------+
- The supporting ASEs, summarized in the table, are individually introduced in the
- clauses below.
- 26.4.1 Remote Operations
- The Remote Operations Service Element (.I.ab:ROSE;) is the means by which the
- asymmetric Message Handling ASEs structure their request-response interactions
- between consuming and supplying open systems.
- The ROSE is defined in Recommendation X.219.
- 26.4.2 Reliable Transfer
- The Reliable Transfer Service Element (.I.ab:RTSE;) is the means by which various
- symmetri and asymmetric Message Handling ASEs convey information objects--
- -especially large ones (e.g., facsimile messages)--between open systems so as to
- ensure their safe-storage at their destinations.
- The RTSE is defined in Recommendation X.218.
- 26.4.3 Association Control
- The Association Control Service Element (.I.ab:ACSE;) is the means by which all
- application associations between open systems are established, released, and in
- other respects managed.
- The ACSE is defined in Recommendation X.217.
- 27. Application Contexts
- In OSI the communication capabilities (i.e., ASEs) of two open systems are
- marshalled for a particular purpose by means of application contexts (.I.ab:ACs;). An AC
- is a detailed specification of the use of an association between two open systems,
- i.e., a protocol.
- An AC specifies how the association is to be established (e.g., what
- initialization parameters are to be exchanged), what ASEs are to engage in peer-to-peer
- communication over the association, what constraints (if any) are to be imposed upon
- their individual use of the association, whether the initiator or responder is the
- consumer of each asymmetric ASE, and how the association is to be released (e.g.,
- what finalization parameters are to be exchanged).
- Every AC is named (by an ASN.1 Object Identifier). The initiator of an
- association indicates to the responder the AC that will govern the association's use by
- conveying the AC's name to it by means of the ACSE.
- An AC also identifies by name (an ASN.1 Object Identifier) the abstract syntaxes
- of the APDUs that an association may carry as a result of its use by the AC's
- ASEs. Conventionally one assigns a name to the set of APDUs associated either with
- each individual ASE or with the AC as a whole. The initiator of an association
- indicates to the responder the one or more abstract syntaxes associated with the AC by
- conveying their names to it via the ACSE.
- The abstract syntax of an APDU is its structure as an information object (e.g.,
- an ASN.1 Set comprising an Integer command code and an IA5 String command
- argument). It is distinguished from the APDU's transfer syntax which is how the information
- object is represented for transmission between two open systems (e.g., one octet
- denoting an ASN.1 Set, followed by one octet giving the length of the Set, etc.).
- The ACs by means of which the various Message Handling services are provided are
- specified in Recommendation X.419. These protocols are known as .I.ab:P1;,
- .I.ab:P3;, and .I.ab:P7;.
- Note The nature of a message's content does not enter into the definition of
- Message Handling ACs because the content is encapsulated (as an Octet String) in the
- protocols by means of which it is conveyed.
-
-
-
-
-
-
-